IV. REMARKS 

Claims 1-1 1 are pending in this application. By this amendment, claims 1 and 1 1 have 
been amended. Claims 12-19 have been added. Applicant does not acquiesce in the correctness 
of the rejections and reserves the right to present specific arguments regarding any rejected 
claims not specifically addressed. Furtlier, Applicant reserves the right to pursue the full scope 
of the subject matter of the original claims in a subsequent patent application that claims priority 
to tlie instant application. Reconsideration in view of die following remarks is respectfully 
requested. 

In the Office Action, claim I is rejected under 35 U,S.C. §1 12 as allegedly being 
indefmite. Claims 1, 3 and 4 are rejected under 35 U.S.C, §l03(a) as allegedly being 
unpatentable over Kraslavsky (U.S. Patent No. 5,699,350), hereafter "Kraslavsky" in view of 
Rune (U.S. Patent No. 6,304,913), hereafter "Rune." Claim 5 is rejected under 35 U.S.C. 
§ 103(a) as allegedly being unpatentable over Kraslavsky in view of Rune and further in view of 
Ogus (U.S. Patent No. 6,587,875), hereafter **Ogus." Claim 2 is rejected under 35 U.S.C. 
§ 103(a) as allegedly being unpatentable over Kraslavsky in view of Rime and Ogus and further in 
view of Spence al (U.S. Patent No. 6,185,600), hereafter Spence. Claims 7-1 1 are rejected for 
similar reasons to claims 1*6. 

A, REJECTION OF CLAIM 1 UNDER 35 U-S.C. §112 

The Office has asserted that claim I is indefinite for failing to particularly point out and 
distinctly clairh the subject matter which applicant regards as tlie invention. Applicant traverses 
^l^^ rejection. Applicant has amended claims 1 and 1 1 to replace ^'pre-determined" with "pre- 
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defl.ned." Applicant asserts that this amendment further clarifies the invention. Accordingly, 
Applicant requests that the objection be withdrawn. 

B. REJECTIOIN OF CLAIMS 1-11 UNDER 35 U.S.C. §1 03(a) 

With regard to the 35 U.S.C. §].03(a) rejection over Kraslavsky in view of Rune, Orgus 
and Spence, Applicant asserts that the cited references do not teach each and every feature of the 
claimed invention. Specifically, with respect to independent claims 1 and 1 1 and dependent 
claim 13, Applicant submits that, contrary to the arguments of the Office, Kraslavsky fails to 
teach or suggest a table for storing a plurality of IPX/SPX network segment addresses and the 
number of hops each segment is from the computer accessing said table. The Office erroneously 
attempts to equate this feature with the table of entry points into various service routines 
provided by the LSL in Kraslavslcy. However, the invention in Krd$Iav$ky deals with 
dynamically reconfiguring frame type assignments and protocol stacks for a network device from 
a remote device. Col.. 2, lines 35-48. The Kraslavsky invention is described, in particular, for 
use with a network interface board for connecting a digital copier and a LAN. Col. 5, lines 56- 
60. In order to accomplish its goal, Kraslavsky uses a Multi-Link Interface Driver (MLJD), 
which . JS the lowest level of network connection software and handles sending and receiving 
of packets to and from the network. CoL 8, lines 33-36; FIG. 9(a). Kraslavsky also has a number 
of protocol stacks that receive packets for the respective protocols, determine what needs to be 
done with the packets and send the packets to the necessary destination. CoL 9, lines 36-40. The 
LSL that the Office refers to is a Link Support Layer that comprises software code that acts as a 
multiplexer between the lowest level MLID and network protocol stacks. Accordingly, the table 
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of entry points into'the various service routines in the LSL referred to by the Office simply 
allows the protocol stack to communicate with the MLID and does not store a plurah'ty of 
IPX/SPX network segment addresses and the number of hops each segment is from the computer 
accessing said table. In contrast, the present invention includes , .a table for storing a plurality 
of IPX/SPX network segment addresses and the number of hops each segment is from the 
computer accessing said tabic/' Claim 1 . As such, the talkie as included in the claimed invention 
does not merely store entry points to access routines for communicating between a jprotocol stack 
and MLTD as does the table in Kraslavsky, but instead stores a plurality of IPX/SPX network 
segment addresses and the number of bops each segment is from the computer accessing said 
table. Tlius, the table of entry points to access routines in Kraslavsky is not equivalent to the 
table as included in the claimed invention. The other cited references do not cure this deficiency. 
Accordingly, Applicant respectfully requests that the Office withdraw its rejection, 

Witli further respect to independent claims 1,11 and 1 2, Applicant respcctfiiUy submits 
that, contrary to the arguments of the Office, Kraslavsky also fails to teach or suggest IPX/SPX 
Routing Information Protocol (RJP) request packet sending means adapted to transmit an RIP 
request packet across an IPX/SPX network. As stated above, the Kraslavsky system includes an 
MLID for communicating with the network, protocol stacks for processing protocol packets, and 
an LSL for multiplexing between the two. Kraslavsky also includes a prescanning program 
opposite the LSL from the MLID that is responsible for identifying which frame types are 
associated with the various protocols. Col. 13, lines 8-12. Both the prescanning program and 
newly-loaded protocol stacks in Kraslavsky register with the LDL to inform the LDL which 
frame types the LDL should provide. Col. 13, lines 1-27; co), 14, lines 37-47. However, these 

09/887,499 Page 12 of 16 

PAGE mr RCVD AT 1M2004 3:30:18 PM [Eastern Standard Time] ' SVR:USPTO-EFXRF-110 ' DNIS:8729306 * CSID:518 449 0047 ' DURATION ([nm-s$):04-34 



registrations are with the software multiplexing LDL and do not transmit an RIP request packet 
across an IPX/SPX network. The prescanning program and newly-loaded protocol stacks in 
Kraslavsky never communicate with the network, only with the LDL. Only the MLID in 
Kraslavsky communicates with the network, and Kraslavsky never discloses that it transmits an 
RIP request packet across an IPX/SPX network. The present invention, in contrast, includes 

. .IPX/SPX Routing Information Protocol (RIP) request packet sending means adapted to 
transmit an RIP request packet across an IPX/SPX network," Claim 1 . As such, in the claimed 
invention, the IPX/SPX Routing Information (RIP) request packet sending means is adapted to 
transmit an RIP request packet across an IPX/SPX network, not merely to register with an 
intermediate software multiplexer as do tlie prescannuig program and newly-loaded protocol 
stacks in Kraslavsky. For the above reasons, the registration of Kraslavsky is not equivalent to 
the transmission of an RIP request packet across an IPX/SPX network as included in the claimed 
invention. The other cited references do not cure this deficiency. Accordingly, Applicant 
requests that the rejection be withdrawn. 

With still ftirther respect to independent claims 1,11 and 1 2, Applicant respectfully 
submits that, contrary to the arguments of the Office, Kraslavsky also fails to teach or suggest 
IPX/SPX Routing Information Protocol (RIP) response packet receiving means adapted to 
receive RJP response packets in response to the RIP request packet. Instead the Kraslavslcy 
system monitors the network, which may be using a variety of protocols, for a request for 
network services. Col 11, lines 1 1-48. However, Kraslavsky never teaches or suggests receiving 
an RIP response packet in response to an RIP request packet. In contrast, the claimed invention 
includes . .IPX/SPX Routing Information Protocol (RIP) response packet receiving means 
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adapted to receive RIP response packets in response to the RIP request packet." Claim L As 
such, the IPX/SPX Routing Information Protocol response packet as included in the claimed 
invention does not merely monitor a network as does the Kraslavsky system, but instead is 
adapted to receive RJP response packets in response to the RIP request packet. For the above 
reasons, the network monitoring of Krasl avsky is not equivalent to the receiving of RTP response 
packets in response to the RIP request packet as included in the claimed invention. The other 
cited references do not cure this deficiency. Accordingly, Applicant requests that the rejection be 
withdrawn. 

With yet still further respect to independent claims 1,11 and 12, Applicant respectfully 
submits that, contrary to the arguments of the Office, Kraslavsky also fails to teach or suggest 
IPX/SPX broadcast means responsive to an application request to transmit an application defined 
packet to network segments. Instead, Kraslavsky teaches that its LSL provides a received frame 
to its pre-scamiing program. Col 13, lines 51-57. However, as stated above, the LSL is simply a 
software interface, and is not a network segment. Col. 9, lines 16-18. Kraslavsky never teaches 
or suggests transmitting an application defined packet to network segments. In contrast, the 
claimed invention includes IPX/SPX broadcast means responsive to an application request to 
transmit an application defined packet to network segments.** Claim I. As such^ the IPX/SPX 
broadcast means as included in the claimed invention does not merely form an interface to 
provide a received fi-ame to the pre-scanning program as does the LSL in Kraslavsky, but rather 
transmits an application defined packet to network segments. For the above reasons, the LSL of 
Kraslavslcy is not equivalent to the IPX/SPX broadcast means as included in the claimed 
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invention. The otlier cited references do not cure this deficiency. Accordingly, Applicant 
requests tliat the rejection be withdrawn. 

With further regard to tlie 35 U.S.C. §1 03(a) rejection over Kraslavsky in view of Rune, 
Applicant asserts that there is no motivation to combine the references. Kraslavsky teaches a 
method of recognizing low level frames depending on the current conftguralion of the proposed 
network card. In contrast, Rune cover$ a method to store in a table the addresses of homologous 
servers and to provide to the requesting client one of the servers that is selected using a "shorter 
distance" concept in a TCP/IP network. Even leveraging Kraslavsky and Rune, an artisan of 
ordinary skill is forced to write ad hoc logic in this multiprotocol application to handle the 
handshake phase between client and server (or peer to peer) when running on a TCP/IP or 
TPX/SPX network. In addition, all of the description in the cited references is focused on low 
level multiprotocol logic* Accordingly, Applicant requests that the rejection be witlidrawn. 

With further respect to independent claim 12, Applicant respectfully submits that the 
cited art fails to teach or suggest a responses filter for filtering the responses to remove responses 
in which the response number of hops is greater than the specified number of hops to produce a 
set of network numbers. Accordingly, Applicants respectfiilly submit that this claim is in 
condition for al lowance. 

With further respect to independent claim 1 1 and with regard to dependent claims 7-10, 
Applicant asserts that the Office's factual assertion that the claims do not teach or define any 
significantly new limitation above and beyond claims 1-6 to warrant particular treatment is 
incorrect. Claims 7-1 1 include features not specified in claims 1-6. For example, Applicant 
asserts that a computer that is a multi-platfonn router also adapted to communicate using a 
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TCP/IP protocol is a new limitation. Furthermore, a computer that is a server is also a new 
limitation. Accordingly, Applicant respectfully requests tJiat the Office support its allegation 
with references that show these limitations. 

With regard to the Office's other arguments regarding dependent claims, Ajjplicant herein 
incorporates tlie arguments presented above with respect to independent claims listed above. In 
addition. Applicant submits that all dependant claims are allowable based on their own distinct 
features. However, for brevity. Applicant will forego addressing each of these rejections 
individually, but reserves the right to do so should it become necessary. Accordingly, Applicant 
respectfully requests that the Office withdraw its rejection. 

V. CONCLUSION 

In light of tlie above. Applicant respectfully submits that all claims are in condition for 
allowance. Should the Examiner require anything further to place the application in better 
condition for allowance, the Examiner is invited to contact Applicant's undersigned 
representative at the number listed below. 



Hoffman, Wamick & D*Alessandro LLC 
Three E-Comm Square 
Albany, New York 12207 
(518) 449-0044 
(518) 449-0047 (fax) 
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Respectfully submitted, 



Date; December 28, 2004 




Ronald A. D'Alessandro 
Reg. No,: 42,456 
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